Method and System for Call Processing

ABSTRACT

According to one embodiment of the invention, a method includes receiving a first setup message transmitted by a first endpoint, the first setup message an attempt by the first endpoint to setup a call with a second endpoint, the setup message sent by the first endpoint to an IP address of a call manager after the first endpoint registered with a gatekeeper, the IP address of the call manager supplied to the first endpoint by the gatekeeper in response to a request by the first endpoint to the gatekeeper for an IP address of the second endpoint. The method further includes attempting to setup the call between the first and second endpoints by transmitting a second setup message to the second endpoint.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. application Ser. No.11/172,102 filed Jun. 30, 2005 and entitled “Method and System for CallProcessing”.

TECHNICAL FIELD OF THE INVENTION

This invention relates generally to communications and more particularlyto a method and system for call processing, which in a specificembodiment involves a method for routing calls in an IP video telephonyenvironment.

BACKGROUND OF THE INVENTION

Communications is becoming increasingly important in today's society. Inparticular, video conferencing has become commonplace and an alternativeto business travel. The proliferation of the internet has enhanced videoconferencing capability, with IP video telephony becoming commonplace.

In one IP telephony example, two endpoints, such as IP video telephones,communicate with each other through the use of a gatekeeper. One exampleof a gatekeeper is a Cisco router running Cisco IOS software. In oneexample implementation, both endpoints register with the gatekeeper.Then, when at first one of the endpoints wishes to communicate withanother endpoint, the first endpoint sends the phone number of the otherendpoint to the gatekeeper. The gatekeeper returns the IP address of theother endpoint. Using the received IP address, the endpoints cancommunicate with each other directly. Gatekeepers can also be used incommunication contexts outside the IP video telephony environment,including transmitting data utilizing only audio media.

Although the use of gatekeepers to process calls is satisfactory forsome purposes it is not entirely satisfactory in all respects.

SUMMARY OF THE INVENTION

According to one embodiment of the invention, a method of processingcalls includes configuring a gatekeeper to forward all dialed phonenumbers to a call manager. The method also includes receiving a signalat the gatekeeper from a first endpoint requesting an IP address of asecond endpoint corresponding to a particular dialed phone number. Inresponse, the gatekeeper transmits to the first endpoint an IP addressof the call manager rather than the IP address of the second endpoint.The call manager is operable to set up a call between the first andsecond endpoints wherein the call does not travel through the callmanager.

Some embodiments of the invention provide numerous technical advantages.Some, none, or all embodiments of the invention may benefit from thebelow described advantages. According to one embodiment of theinvention, a method is provided that allows a gatekeeper to relinquishcontrol of all calls to a call manager. Because the call manager isprocessing the calls, certain advanced call processing functionality maybe utilized that is not traditionally available with gatekeepers. Forexample, the call manager may effect call permission routing, time ofday routing, bandwidth control and called or calling number translation,allowing better control over which endpoints are allowed to call eachother and how those calls are routed.

Other embodiments should be readily apparent to those skilled in theart.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and itsadvantages, references now made to the following description, taken inconjunction with the accompanying drawings, in which:

FIG. 1 is a block diagram illustrating a communication system accordingto the teachings of the invention;

FIG. 2 is a block diagram illustrating portions of the system of FIG. 2Aaccording to the teachings of the invention;

FIG. 2B is a call flow diagram illustrating a call flow according to theteachings of the invention; and

FIG. 3 is a flowchart illustrating a method for call processingaccording to the teachings of the invention.

DETAILED DESCRIPTION OF THE INVENTION

Embodiments of the present invention and its advantages are bestunderstood by referring to FIGS. 1 through 3 of the drawings, likenumerals being used for like and corresponding parts of the variousdrawings.

FIG. 1 is a block diagram illustrating a communication system 10according to the teachings of the invention. System 10 is a videoconferencing communication system which is used to illustrate teachingsof the invention; however, the teachings of the invention are alsoapplicable outside the video conferencing context. Communication system10 includes a first endpoint 12 and a second endpoint 14. In thisexample, endpoints 12 and 14 are video conferencing endpoints such as avideo terminal with an associated IP telephone; however, as used hereinendpoints refer to a device capable of transmitting or receiving a call,which may be a video call or an audio call.

Communication system 10 also includes a call manager cluster 16. Callmanager cluster 16 includes a plurality of call managers 20. Callmanagers 20 are devices that perform a switching function toappropriately route calls. One example of a call manager is the CiscoCallManager which resides on the Cisco 7800 Media Convergence Server.Unlike gatekeepers, which are described below, a call manager canrestrict the ability of one endpoint from reaching another, as well asprovide additional enhanced functionality, in some embodiments. Networksrelying on gatekeepers are traditionally hard to manage, difficult toemploy, and lack certain administrative controls. Cisco CallManageraugments the limitations of the gatekeeper, providing the administratora greater degree of control over the network and how calls are routed;for instance, Cisco CallManager can restrict the ability from oneendpoint to reach another, and includes the capability to implement callpermissions (who is allowed to call whom), determine how a call isrouted based on, for example, the time of day, and perform numbertranslations, such as translation of a calling or called number.

Communication system 10 also includes a gatekeeper 22. As described ingreater detail below, according to the invention, gatekeeper 22 directsall calls to one of the call managers 20 so that the call manager 20 mayperform all call routing and bandwidth control. Gatekeeper 22 is adevice that registers endpoints by receiving and correlating their IPaddresses and associated phone numbers. Gatekeeper 22 provides an IPaddress of an endpoint 12, to endpoint 14 in response to receiving anendpoint's telephone number and a request to provide its IP address. Oneexample of a gatekeeper is implemented in Cisco Access Routers, 2600 or3600 having Cisco IOS software, including but not limited to seriesnumbers 2600, 2800, 3600, 3700, 3800, and 7200; however, other routersmay be used.

Conventionally videoconferencing networks relied on gatekeepers toperform all device registration management, call routing, and bandwidthcontrol. One example of such a gatekeeper, the Cisco IOS Gatekeeper,(formerly known as the Multimedia Conference Manager), provided thesefunctions. The teachings of the invention recognize that some callmanagers, such as Cisco CallManager Release 4.0, for example, providevastly superior call routing and bandwidth controls than gatekeepers do,and therefore it is desirable to configure the H.323 devices in thenetwork to route their calls through call manager 22.

Therefore, according to the teachings of the invention, all calls intogatekeeper 22 are redirected to call manager 20 for handling all callrouting, allowing communication system 10 to benefit from the enhancedfunctionality provided by call manager 20. As an example, gatekeeper 22generally does not have the capability to provide advanced functionalitysuch as effecting calling permissions, time of day routing, and calledor calling number translations. Thus by routing all calls through callmanager 20 rather than routing by gatekeeper 22, this enhancedfunctionality and other enhanced functionality associated with callmanagers may be provided. Additional details are described below inconjunction with FIGS. 2A through 3.

FIG. 2A is a block diagram illustrating portions of communication system10 according to the teachings of the invention. The operation of oneembodiment of the invention is described with respect to FIG. 2A. Whenendpoint 12 desires to place a call to endpoint 14, it issues a request30 to gatekeeper 22 for the IP address associated with endpoint 14.Endpoint 12 identifies endpoint 14 in message 30 by endpoint 14'stelephone number. Conventionally, gatekeeper would respond with amessage including the IP address of endpoint 14. However, according tothe teachings of the invention, gatekeeper 22 responds with a message 32that includes the IP address of call manager 20. Thus, endpoint 12receives an IP address of call manager, believing it to be the IPaddress of endpoint 14.

In response, endpoint 12 sends a setup message 34 to call manager 20,believing the setup message is being sent to endpoint 14. In oneembodiment, the setup message may include the calling party's (endpoint12) telephone number as well as the called party's (endpoint 14)telephone number. Call manager 20 recognizes setup message 34 as anattempt to set up a message between endpoint 12 and endpoint 14. Inresponse, call manager issues its own setup message 36 to endpoint 14.Setup message 36 may include the telephone number of the calling party(endpoint 12), and the telephone number of the called party (endpoint14), or call manager 20 may manipulate one or both of these numbers sothat the calling and/or called numbers appear differently to endpoint14. Endpoint 14 receives the setup message 36 and may initiate a call 38in which call media may be exchanged between endpoint 12 and endpoint14. It is noted that the communication of call media between endpoints12 and 14 may occur without that media flowing through call manager 20.

Because the call routing is performed by call manager 20, advancedfunctionality possessed by call manager 20 may be utilized in processingcalls between endpoints 12 and 14, including calling permissions, timeof day routing, least-cost routing, called and/or calling numbertranslations and bandwidth controls.

In order for gatekeeper 22 to return message 32 having the IP address ofcall manager 20 rather than the IP address of endpoint 14, call managermust be configured to effect such a message. According to the teachingsof the invention, gatekeeper 22 is configured to route all phone numbersreceived in message 30 to call manager 20. This is effected, in oneembodiment, by routing all dialed numbers starting with the number 0through 9 to call manager 20. Example details associated with oneparticular embodiment of such configuration are described in greaterdetail below.

According to one embodiment, the use of zone prefixes enables gatekeeper22 to route calls to the correct zone, while technology prefixes enablegatekeeper 22 to route calls to the correct gateway device, which may becall manager 20. In one embodiment of gatekeeper 22, zones are used togroup endpoint types to restrict them from dialing each other directlywithout going through call manager 20. Therefore, four zones may becreated on gatekeeper 22. Those four zones include a client zone, a callmanager zone, a gateway zone, and a Multipoint Control Unit (MCU) Zone(not explicitly shown). The client zone is a single zone for all theendpoints associated with a given call manager cluster 16. The callmanager zone is a single zone for all the call manager servers in acluster 16. The gateway zone is a single zone for all the H.320 gatewaysassociated with a given call manager cluster 16, in one example. The MCUzone is a single zone for all the MCUs associated with a given callmanager cluster 16. These zones enable configuration of the gatekeeperto block endpoints from calling MCUs and gateways directly and to blockendpoints, MCUs and gateways from calling each other directly. Instead,all calls are routed to the call manager zone through the use of zoneprefixes.

In one example, gatekeeper 22 is configured to route all calls to thecall manager zone and then to the correct call manager within that zone.In one embodiment, all calls are routed to the call manager zone byconfiguring ten zone prefixes (0 through 9) for that zone, asillustrated in the following example:

  zone prefix [callmanager_zone] 0* zone prefix [callmanager_zone] 1*zone prefix [callmanager_zone] 2* zone prefix [callmanager_zone] 3* zoneprefix [callmanager_zone] 4* zone prefix [callmanager_zone] 5* zoneprefix [callmanager_zone] 6* zone prefix [callmanager_zone] 7* zoneprefix [callmanager_zone] 8* zone prefix [callmanager_zone] 9*With the zone prefixes defined in this way, no matter what number anendpoint dials, the call will always be routed to call manager 20.

In specific implementations involving the use of a Cisco CallManager ascall manager 20, the H.225 gatekeeper-controlled trunk in CiscoCallManager is configured to register in the CallManager Zone. Thistrunk registers with a technology prefix, and in one example thattechnology prefix is 1#. It is desirable in this specific implementationthat this technology prefix is configured to be the default technologyprefix in gatekeeper 22. The following command may be used to configurethe technology prefix in gatekeeper 22.

-   -   gw-type-prefix 1# default-technology

When gatekeeper 22 matches the dialed number to a zone prefix, it thenlooks inside that zone to find a matching E.164 address. In oneimplementation, there will be no E.164 addresses registered in theCallManager Zone, so gatekeeper 22 will default to routing the call to agateway that is registered with the default technology prefix in thatzone, which in this case will be Cisco CallManager.

In the specific example described above, when gatekeeper 22 routes acall to the H.225 trunk of Cisco CallManager 20, Cisco CallManager 20looks at the source IP address of the calling endpoint 12 and tries tomatch that address to a device in its database. If it finds a matchingIP address, Cisco CallManager 20 applies that device's callingpermissions and other relevant settings. If it does not find a match,Cisco CallManager 20 may apply the calling permissions and otherrelevant settings of the trunk, or may reject the call altogether.

For devices configured as H.323 gateways in Cisco CallManager 20 (forexample, H.320 gateways and MCUs would be configured as H.323 gatewaydevices), the H.225 handler representing that device in CiscoCallManager 20 may register with every Cisco CallManager 20 server inthe Cisco CallManager 16 redundancy group defined for that device. ForH.323 clients, the H.225 handler representing these devices registerswith only the primary Cisco CallManager 20 server for that client'sCisco CallManager group 16 (FIG. 1). Therefore, gatekeeper 22 may beconfigured to always route calls to the primary server 20. If theprimary server 20 goes down and unregisters from gatekeeper 22,gatekeeper 22 should then route all calls to the secondary server 20,and so on.

To configure gatekeeper 22 to prioritize the routing of calls to thevarious Cisco CallManagers 20 servers in the cluster 16, the gw-priorityargument may be used at the end of the zone prefix command, asillustrated in the following example:

zone prefix [callmanager_zone] 0* gw-priority 10 [callmanager-1] zoneprefix [callmanager_zone] 0* gw-priority 9 [callmanager-2] zone prefix[callmanager_zone] 0* gw-priority 8 [callmanager-3] zone prefix[callmanager_zone] 1* gw-priority 10 [callmanager-1] zone prefix[callmanager_zone] 1* gw-priority 9 [callmanager-2] zone prefix[callmanager_zone] 1* gw-priority 8 [callmanager-3] zone prefix[callmanager_zone] 2* gw-priority 10 [callmanager-1] zone prefix[callmanager_zone] 2* gw-priority 9 [callmanager-2] zone prefix[callmanager_zone] 2* gw-priority 8 [callmanager-3] ... zone prefix[callmanager_zone] 9* gw-priority 10 [callmanager-1] zone prefix[callmanager_zone] 9* gw-priority 9 [callmanager-2] zone prefix[callmanager_zone] 9* gw-priority 8 [callmanager-3]

To configure the correct zones for the endpoints 12, 14, the zone subnetcommand may be used in gatekeeper 22 to define which IP addresses or IPaddress ranges are permitted to register in each zone. Either aparticular host address or a subnet of addresses may be specified. ForCisco CallManager, gateway, and MCU zones, the specific host addressesmay be used, for example, as illustrated in the following example:

  no zone subnet [callmanager_zone] default enable zone subnet[callmanager_zone] 10.1.1.101/32 enable zone subnet [callmanager_zone]10.1.1.102/32 enable zone subnet [callmanager_zone] 10.1.1.103/32 enable! no zone subnet [mcu_zone] default enable zone subnet [mcu_zone]10.1.1.201/32 enable ! no zone subnet [gateway_zone] default enable zonesubnet [gateway_zone] 10.1.1.301/32 enable zone subnet [gateway_zone]10.1.1.302/32 enableFor the client zone, the IP addresses of the endpoints do not need to beexplicitly allowed. Instead, the IP addresses of all the CiscoCallManagers, MCUs, and gateways can be denied, with the default enablecommand to allow all other address ranges in that zone. For example:

  zone subnet [client_zone] default enable no zone subnet [client_zone]10.1.1.101/32 enable no zone subnet [client_zone] 10.1.1.102/32 enableno zone subnet [client_zone] 10.1.1.103/32 enable no zone subnet[client_zone] 10.1.1.201/32 enable no zone subnet [client_zone]10.1.1.301/32 enable no zone subnet [client_zone] 10.1.1.302/32 enable

In the particular example of the Cisco CallManager Release 4.0 for useas call manager 20, the static IP addresses for all H.323 clients, MCUs,and gateways may be used in order to define them in Cisco CallManagerAdministration.

In a particular implementation involving the Cisco IOS Gatekeeper, it isnoted that the Cisco IOS Gatekeeper previously offered an H.323 Proxyfunction as part of the Multimedia Conference Manager (MCM) feature set.The MCM Proxy is not compatible with Cisco CallManager and is thereforedisabled, in one embodiment. The Cisco IOS Gatekeeper, by default, isconfigured to use the MCM Proxy for inter-zone calls to and from H.323clients. In other words, when a local zone is created on the Cisco IOSGatekeeper, its default configuration is:

-   -   use-proxy <zone_name> default [inbound-to|outbound-from]        terminals        Although particular examples of configuration of one example        gatekeeper have been described, it should be understood that        various changes, substitutions, and alterations can be made        therein without departing from the spirit and scope of the        present invention as defined by the appended claims.

FIG. 2B is a call flow diagram illustrating the call flow for theexample of FIG. 2A. FIG. 2B includes endpoints 12 and 14, gatekeeper 22,and call manager 20. At a step 130 endpoint 12 sends a request togatekeeper 22 for the IP address associated with endpoint 14. In oneexample implementation, message 30 is an admission request that includesthe telephone number of endpoint 14. In response, at step 132 gatekeeper22 sends a message 32 to endpoint 12 with the IP address of call manager20, rather than the IP address of endpoint 14. In one exampleimplementation this is effected by gatekeeper 22 issuing an admissionconfirmation message, as illustrated.

At step 134, endpoint 12 issues a setup message 34 trying to set up acall with endpoint 14. In addition to the calling party's (endpoint 12)telephone number, setup message may also include the called party's(endpoint 14) telephone number as well as additional data. As describedabove, message 34 is transmitted to call manager 20, because endpoint 12received the call manager 20's IP address as being associated with thecalled party's telephone number rather than the IP address of endpoint14. At step 136 a setup message is transmitted from call manager 20 toendpoint 14 that includes the calling party's (endpoint 12) number aswell as the called party's (endpoint 14) telephone number. It is notedthat at this point call manager 20 may implement routing logic, such asdetermining whether endpoint 12 has permission to call endpoint 14, aswell as number translations and other routing logic. Thus, enhancedfunctionality associated with call routing that is normally availablewhen call managers are used is available even in the context in whichendpoints register with a gatekeeper. At step 138, endpoint 14 respondsto the request initiated by endpoint 12 to set up a call and mayexchange call media with endpoint 12, without transmitting the callmedia through call manager 20.

FIG. 3 is a flowchart illustrating a method 200 for call processingaccording to the teachings of the invention. The method begins at step202. At step 204 a gatekeeper is configured to forward all calls to acall manager. In one example, this configuration may include configuringthe gatekeeper to forward all phone numbers that begin with the dialednumber 0 through 9 to the call manager. Example details for implementingsuch configuration are described above. At a step 206, a signal isreceived at the gatekeeper from a first endpoint requesting an IPaddress of a second endpoint corresponding to a particular dialed phonenumber. In response, at step 208, a message is transmitted to the firstendpoint that returns the IP address of a call manager rather than theIP address of the second endpoint. This returning of the IP address ofthe call manager rather than the IP address of the second endpointeffects transfer of call routing to the call manager rather than thegatekeeper, effectively relinquishing control of the call to the callmanager.

At step 210, the first endpoint sends a setup message to the callmanager thinking it is sending the setup message to the second endpointattempting to set up a call. As described above, such a setup messagemay include the phone number of both the called and calling parties, aswell as additional information. In response to receiving the first setupmessage, the call manager sends a setup message at step 211 to thesecond endpoint attempting to set up a call between the first endpointand the second endpoint. This second message may include the phonenumber(s) of both the calling endpoint and the called endpoint, as wellas additional information. At step 212, the second endpoint receives therequest to set up a call and may respond by transmitting call mediabetween the first and second endpoints. The method concludes at step214.

Although the present invention and its advantages have been described indetail, it should be understood that various changes, substitutions, andalterations can be made therein without departing from the spirit andscope of the present invention as defined by the appended claims.

What is claimed is:
 1. A call manager operable to: receive a first setupmessage transmitted by a first endpoint, the first setup message anattempt by the first endpoint to setup a call with a second endpoint,the setup message sent by the first endpoint to an IP address of thecall manager after the first endpoint registered with a gatekeeper, theIP address of the call manager supplied to the first endpoint by thegatekeeper in response to a request by the first endpoint to thegatekeeper for an IP address of the second endpoint; and attempt tosetup the call between the first and second endpoints by transmitting asecond setup message to the second endpoint.
 2. The call manager ofclaim 1, wherein the first and second endpoints comprise IP telephones.3. The call manager of claim 1, wherein the first and second setupmessages each comprise a telephone number of the second endpoint atelephone number of the first endpoint.
 4. The call manager of claim 1,further operable to implement one or more call permissions to restrictthe ability of a particular endpoint from reaching another endpoint, thecall permissions indicating which endpoint is allowed to call with otherendpoint.
 5. The call manager of claim 1, further operable to determinehow calls should be routed based on time.
 6. The call manager of claim1, further operable to provide: least-cost routing; calling and callednumber translation; and bandwidth controls.
 7. The call manager of claim1, wherein after the second setup message is transmitted to the secondendpoint, call media is exchanged between the first and second endpointswithout the call media flowing through the call manager.
 8. A methodcomprising: receiving a first setup message transmitted by a firstendpoint, the first setup message an attempt by the first endpoint tosetup a call with a second endpoint, the setup message sent by the firstendpoint to an IP address of a call manager after the first endpointregistered with a gatekeeper, the IP address of the call managersupplied to the first endpoint by the gatekeeper in response to arequest by the first endpoint to the gatekeeper for an IP address of thesecond endpoint; and attempting to setup the call between the first andsecond endpoints by transmitting a second setup message to the secondendpoint.
 9. The method of claim 8, wherein the first and secondendpoints comprise IP telephones.
 10. The method of claim 8, wherein thefirst and second setup messages each comprise a telephone number of thesecond endpoint a telephone number of the first endpoint.
 11. The methodof claim 8, wherein the second setup message comprises a telephonenumber of the second endpoint a telephone number of the first endpoint.12. The method of claim 8, further comprising implementing one or morecall permissions to restrict the ability of a particular endpoint fromreaching another endpoint, the call permissions indicating whichendpoint is allowed to call with other endpoint.
 13. The method of claim8, further comprising determining how calls should be routed based ontime.
 14. The method of claim 8, further comprising: providingleast-cost routing; providing calling and called number translation; andproviding bandwidth controls.
 15. Logic encoded in non-transientcomputer-readable media, the logic operable, when executed by one ormore processors, to: receive, a first setup message transmitted by afirst endpoint, the first setup message an attempt by the first endpointto setup a call with a second endpoint, the setup message sent by thefirst endpoint to an IP address of a call manager after the firstendpoint registered with a gatekeeper, the IP address of the callmanager supplied to the first endpoint by the gatekeeper in response toa request by the first endpoint to the gatekeeper for an IP address ofthe second endpoint; and attempt to setup the call between the first andsecond endpoints by transmitting a second setup message to the secondendpoint.
 16. The logic of claim 15, wherein the first and secondendpoints comprise IP telephones.
 17. The logic of claim 15, wherein thefirst and second setup messages each comprise a telephone number of thesecond endpoint a telephone number of the first endpoint.
 18. The logicof claim 15, further operable to implement one or more call permissionsto restrict the ability of a particular endpoint from reaching anotherendpoint, the call permissions indicating which endpoint is allowed tocall with other endpoint.
 19. The logic of claim 15, further operable todetermine how calls should be routed based on time.
 20. The logic ofclaim 15, further operable to provide: least-cost routing; calling andcalled number translation; and bandwidth controls.